HAL RAMECC migration: List of applicable concepts ¶
This section provides information about the HAL RAMECC applicable architecture concepts.
Concepts for RAMECC ¶
|
Concept |
Description |
|---|---|
|
HAL RAMECC APIs rely now on LL APIs rather than performing direct register access. |
|
|
Define statements and enumerations redirected to LL equivalents |
HAL RAMECC define statements and enumerations are based on LL define statements. |
|
All hardware macros have been removed from the HAL RAMECC driver, and equivalent services are ensured through the LL APIs. |
|
|
HAL RAMECC APIs return status using the type
|
|
|
There is no need for error management in the RAMECC driver, as no error conditions are generated by this peripheral. |
|
|
All TypeDef parts of the HAL RAMECC driver have been removed and replaced by
|
|
|
For the HAL RAMECC driver, large macros have been replaced by inline functions to maintain code consistency, improve readability, and benefit from compiler optimization. Inline functions also offer better support for debugging and strict type management, reducing the risk of errors. |
|
|
Const keywords have been added to non-modifiable pointers to ensure that either the pointer itself or the data it points to cannot be modified. This enhances code safety and readability, prevents unintended modifications, and renders code more robust and maintainable. |
|
|
Replace Finite Parameter Defines (Including PPP Instances) with Enum Types at HAL Levels. |
Finite parameters (including RAMECC instances) have been converted into enumerated types (enums) at HAL level. This improves code readability, maintainability, and type safety. |
|
Add HAL_PPP Prefix to All HAL Peripheral APIs (Defines, Macros, Types, and Functions). |
All HAL RAMECC functions start with
|
Other HAL RAMECC changes ¶
|
Concept |
Consideration |
|---|---|
|
Remove the handle and use instance as parameter of the various HAL functions including the
|
The handle and initialization structures have been removed, and the instance passed directly to the various RAMECC functions is now used instead. |
|
Split global and monitor APIs to let the user either handle the RAMECC by monitor (that is, by RAM) or all at once through global APIs. |
In HAL1, the
|